Debian Packages
Donate
Which Kicksecure Debian packages are safe to remove? What is a meta package? What other packages do Kicksecure meta packages install? Which packages should never be removed?
Introduction
[edit]It is safe to run sudo apt autoremove so long as the specific Kicksecure machine meta package is kept for the Kicksecure or Kicksecure-Qubes platform. In other words, these packages should not be in the list of autoremoved packages.
Kicksecure Xfce
- 17:
kicksecure-xfce - 18:
kicksecure-vm-gui-lxqt
Kicksecure CLI
- 17:
kicksecure-cli - 18:
kicksecure-vm-server
Kicksecure-Qubes GUI
- 17:
kicksecure-qubes-gui - 18:
kicksecure-qubes-gui-lxqt
Kicksecure-Qubes CLI
- 17:
kicksecure-qubes-cli - 18:
kicksecure-qubes-server
Derivatives such as Whonix®
which are based on Kicksecure:
- See derivative (Whonix®) specific documentation instead of this wiki page. [1]
It is actually a good idea to safely run sudo apt autoremove according to the following instructions on this wiki page to make sure extraneous packages which might no longer be recommended for default installation are removed.
Re-install Meta Packages and Safely Run Autoremove
[edit]1. Update the package lists.
sudo apt update
2. Ensure a proper meta package is installed. [2]
Platform specific. Select your platform.
3. Auto remove packages.
sudo apt autoremove
4. Reconfirm a proper meta package is still installed.
Repeat step two.
5. Done.
The procedure of safely running sudo apt autoremove is complete.
Related: Kicksecure Factory Reset
Changed Configuration Files
[edit]Be careful if a message like this appears.
Configuration file '/etc/apparmor.d/usr.bin.sdwdate'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** usr.bin.sdwdate (Y/I/N/O/D/Z) [default=N] ?
For general advice, see: Changed Configuration Files.
Related:
Package Version Check
[edit]If you need to check your package version, use dpkg -l package-name where package-name is the package you wish to check.
dpkg -l package-name
Your output should look like this:
Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-=================================== ii grep 3.8-5 amd64 GNU grep, egrep and fgrep ii package-name 0.1 amd64 package-description
If you wish to independently verify the version, you can either access the github of a package and check its changelog.
See list of github repositories.
Go to a github repository. Example github repository:
Note: Replace the example repository with the actual repository you wish to version check.
Kicksecure GitHub sdwdate repository
Click on the debian sub folder.
Click on the changelog file. Example /debian/changelog file:
On the very top of the changelog is the latest version number.
Note: Source code version might be ahead of repository version.
related: Package Upgrade Policy
Repository Version Check
[edit]How to view the version number using Kicksecure repository deb.kicksecure.com (or for Debian packages or if using a derivative such as Whonix)?
Since a convenient web interface such as packages.debian.org hasn't been implemented yet for Kicksecure (and Whonix) [3] has not been implemented yet, this is a bit difficult.
- Go to https://deb.kicksecure.com
- Click on "
dists" [4] - Click on the release codename you're interested in such as "
bookworm". [5] - Click on the component. Most likely "
main". [6] - Click on the architecture. Most likely "
binary-amd64". [7] - Click on the "
Packages" file. [8] - Read the first 100 lines of that file to get an idea what it does.
- Search the file for the package you're interested in such as for example: package: sdwdate
- Result might be as follows.
Package: sdwdate Version: 3:25.8-1
Interpretation:
- The
3:can be ignored. That is the version epoch. - The
-1can also be ignored. That is the Debian package revision number which is not used much yet. - Ignoring these two parts, version number at time of writing was
25.8.
Advanced Topics
[edit]
Packages FAQ
[edit]| Question | Answer |
|---|---|
| What is the disadvantage of removing a meta package? | The disadvantage is any changes in package dependencies will not be automatically processed by the system when it is update.
For example the See also: Technical Information. |
| Which meta packages are safe to remove? | Use apt-cache to see the package description.
apt-cache package-name It will include either:
Note the Removal Instructions below! When that entry is understood, feel free to remove any desktop specific meta packages. |
| Which packages do Kicksecure meta packages install? | Refer to the following files:
Or use for example. apt-cache show kicksecure-packages-recommended-gui |
| Which meta packages should never be removed? | Do not remove any packages which include the name dependencies, unless the implications are fully understood.
TODO: document |
How to uninstall qubes-core-agent-passwordless-root without also uninstalling kicksecure-qubes-gui or kicksecure-qubes-cli?
|
dummy-dependency --purge qubes-core-agent-passwordless-root |
dummy-dependency
[edit]dummy-dependency [10] (man page) can be used to install a dummy dependency package in place of a real dependency package. This allows:
- A) the uninstallation of packages that are normally not uninstallable, without removing a (meta) package that depends on the original package. And/or;
- B) avoiding the installation of dependency packages that are considered problematic, such as GeoClue (due to privacy concerns associated with GeoClue), which might be pulled as a dependency.
Removal Instructions
[edit]Syntax.
Notes:
- Optional:
--purge. Same asapt-get purge. - Optional:
--yes. Does not ask for confirmation.
sudo dummy-dependency --yes --purge package-name
Example.
Note: Replace user-sysmaint-split with the actual package you want to remove.
- Replace
user-sysmaint-splitwith the actual package you want to remove. - Optional:
--purge. Same asapt-get purge. - Optional:
--yes. Does not ask for confirmation.
sudo dummy-dependency --yes --purge user-sysmaint-split
forum topic: Issues with removal of specific packages by users / builders.
Technical Information
[edit]
This section provides technical information for interested readers and can be skipped.
The underlying technical issues with meta packages are not caused by Kicksecure, but instead have been inherited from Debian. Those are also described here:
- The Metapackage Problem and apt autoremove
- Uninstalling a single component of a meta-package
- Debian bug report: Weak-Depends - something in the middle between 'Recommends:' and 'Depends:'
- RFC: "Recommended bloat", and how to possibly fix it
- apt: autoremove fails to remove garbage packages with unrelated Suggests links
The Debian manual also provides further information about meta packages:
The Kicksecure build script installs all packages using apt --no-install-recommends. [11] The --no-install-recommends option is being used to prevent installation of many additional packages that are unwanted. For example:
kicksecure-packages-recommended-gui(used to)Depends: gwenview.- gwenview
Recommends: kamera. - Without using
--no-install-recommends,kamerawould also be installed and then pull its ownDepends:as well. kamera[+ dependencies] would not be useful to have installed by default on Kicksecure as it would cost unnecessary disk space. There are many more examples which could end up installing packages by default that are unrecommended for privacy reasons.
Since the --no-install-recommends option is used, meta packages like kicksecure-packages-recommended-gui must use the Depends: field and cannot use the Recommends: field. (Since no packages would be installed then.)
Even if Kicksecure could and did use the Recommends: field, new packages added to the Recommends: field would not be installed when the meta package that Recommends: them gets upgraded. This is because packages listed after the Recommends: field only get installed during their initial sudo apt install package-name installation.
Some readers might notice that despite this explanation, kicksecure-meta-packages's debian/control file uses the Recommends: field anyway. This is not a contradiction because it may be useful for a later Kicksecure distribution morphing installation method use case.
Forum discussion:
Issues with removal of specific packages by users / builders
See Also
[edit]- Configuration Drop-In Folders
- Reset Configuration Files to Vendor Default
- Kicksecure Factory Reset
- Packages for Debian Hosts
- Kicksecure APT Repository
- Building and Update Kicksecure from Source Code
Footnotes
[edit]- ↑ Because derivatives of Kicksecure install additional meta packages.
- ↑
The apt install commands are not strictly required if these packages are already installed. However, the simplest approach is to run these commands to follow the documentation as is.
- Either the packages are already installed: then the command does no harm.
- Or the packages are not installed: then these commands are necessary.
- ↑
packages.debian.org APT package repository web interface for deb.kicksecure.com / deb.whonix.org
- ↑
https://deb.kicksecure.com/dists/
- ↑
https://deb.kicksecure.com/dists/bookworm/
- ↑
https://deb.kicksecure.com/dists/bookworm/main/
- ↑
https://deb.kicksecure.com/dists/bookworm/main/binary-amd64/
- ↑
https://deb.kicksecure.com/dists/bookworm/main/binary-amd64/Packages
- ↑
Depends:field indebian/control - ↑
Kicksecure GitHub helper-scripts repository subpath
- ↑
Function
pkg-install-maybein Kicksecure GitHub derivative-maker repository subpath
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2025 ENCRYPTED SUPPORT LLC
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!